An operating system is a large, complex piece of software whose primary function is the management of hardware and software resources of a data processing system such as processors, memory and storage. Storage management, in turn, involves the organization of storage devices, such as disks, into logical groupings to achieve various performance and availability characteristics. For example, the disks may be arranged to create individual volumes or concatenations of volumes, mirror sets or stripes of mirror sets, or even redundant arrays of independent disks (RAID). The data processing platform on which the operating system executes to provide such management functions typically includes a host computer coupled to a storage adapter or controller. The operating system functionally organizes this platform by, inter alia, invoking input/output (I/O) operations in support of software processes or applications executing on the computer.
A storage architecture of the operating system decomposes management of the storage devices into individual components and defines their functional operations with respect to the flow of information and control among them. The individual components include an I/O subsystem and a file system, each of which is generally independent of one another and interact according to interfaces defined by the architecture. The I/O subsystem provides an efficient mode of communication between the computer and the disks that allows programs and data to be entered into the memory of the computer for processing; the subsystem also enables the results obtained from computations of that information to be recorded on the disks.
The file system contains general knowledge of the organization of information on the storage devices and provides algorithms that implement properties/performance of the desired storage architecture. To that end, the file system is a high-level software entity comprising a collection of program modules, e.g., software drivers, that incorporate a command set for the storage devices/disks. Typically, the operating system implements a file system to logically organize the information as a hierarchical structure of files on the disks.
I/O processing is typically performed under the auspices of the file system in that applications typically interact with the file system to manipulate (i.e., read or write) the files. I/O subsystems, on the other hand, interact with disks at lower software levels by manipulating blocks of data. Accordingly, a single I/O transaction operation issued by an application to the file system may spawn into many I/O transfer operations between the I/O subsystem and disks; that is, there may be multiple data transfers between the lower-layer software entities and the actual hardware devices.
Requests to perform I/O transactions are generally serial in nature. Upon requesting data to be read from or written to a file, the application program typically suspends execution and the request is processed by the file system and I/O subsystem. The file system and I/O subsystem are composed of many layers of software driver code that is commonly referred to as an I/O stack. FIG. 1 is a schematic block diagram of a conventional I/O stack 100 comprising a file system driver 102, a logical volume driver 104, a disk class driver 106 and device-specific drivers, such as small computer system interface (SCSI) port and miniport drivers 108, 110.
The organization of a file system and I/O subsystem within a hardware platform vary among conventional storage architectures. FIG. 2A is a block diagram of a traditional storage architecture 200 having a file system 202 and I/O subsystem 204 that are organized to execute entirely on a host computer 206. In response to an I/O transaction request issued by an application, the host processor executes the software code of the file system and I/O subsystem needed to transfer data from disk to the host memory. In this architecture, the host processor actually executes the code of the I/O stack twice for the I/O transaction: once as the transaction descends the stack and again as the results of the transaction are returned to the application. Execution of I/O operations for this type of architecture clearly consumes significant computer resources.
To avoid such consumption of resources, some storage architectures alter the arrangement of their file systems and I/O subsystems. FIG. 2B illustrates a conventional RAID controller architecture 210 wherein the file system 212 is contained within the host computer 216 and the I/O subsystem 214 is distributed between the host computer and controller 218. Most implementations of this architecture are configured to execute RAID-related operations by transferring discrete block-oriented requests between the file system and controller. When these requests complete, however, the host processor is notified by means of interrupts, i.e., events that change the normal flow of instruction execution by the host processor. For this type of architecture, there may be many interrupts associated with a single transaction; since each interrupt must be serviced by the host processor, this architecture results in inefficient use of the processor.
Other storage architectures provide their file systems and I/O subsystems entirely on the controller. The host computer 226 of FIG. 2C interacts with the controller 228 in accordance with a conventional client-server computing model 220 wherein the host computer ("client") forwards each I/O transaction to the controller ("server") typically across an interconnection such as a network; notably, all transactions are sent to the controller and none are serviced locally at the host computer. An example of such an architecture is described in U.S. Pat. No. 5,163,131 titled Parallel I/O Network File Server Architecture by Edward J. Row et al, issued on Nov. 10, 1992.
Row discloses a server-specific I/O architecture that is optimized for file operations of a Unix file server. The file server architecture comprises one or more network controllers, one or more file controllers, one or more storage processors, and a memory interconnected by a message passing bus and operating in parallel with the Unix host. Client requests for file operations are transmitted to a file controller which, independently of the Unix host, manages a virtual file system of a mass storage device coupled to the storage processors. Although this architecture relieves the host processor from I/O processing, it also adversely affects file system latency, i.e., the period of time between the issuance of an I/O transaction request by an application to the file system and the completion of that request by the file system.
In general, file system latency increases with an architecture having a file system that is remote from the processing platform on which the application executes; another example of such an architecture is described in U.S. Pat. No 5,463,772 titled Transparent Peripheral File Systems with On-board Compression, Decompression and Space Management by Bruce A. Thompson et al, issued on Oct. 31, 1995. Here, a peripheral file system is disclosed that may be embedded in a mass storage device, a lump in an interconnecting interface cable or on a smart interface card in the backplane of a host computer. Since Thompson discloses a file system that is remote from the host, file system latency is again affected. Latency of an I/O request is a determinative indication of overall file system performance and the present invention is directed to reducing file system latency.
In a conventional client-server computing environment, I/O capacity and storage management are also significant issues, particularly for the server. I/O capacity is defined as throughput at a certain latency, e.g., 500 megabits per second at a latency not to exceed 10 milliseconds. Customers typically purchase servers to support a predetermined number of clients at a predetermined I/O capacity. As their organizations grow, however, these customers may add more clients to the server; as a result, the server may not be able to generate sufficient capacity to meet the demands of the clients and the server becomes a bottleneck. The present invention is further directed to alleviating this server bottleneck problem.
Therefore, it is an object of the present invention to provide a storage architecture of a data processing system that increases the efficiency of a host computer processor.
Another object of the present invention is to provide a storage architecture of a data processing system that is scalable in terms of I/O capacity and bandwidth.
Yet another object of the present invention is to provide a file system of a data processing system that improves file system latency and overall system performance.
Still yet another object of the present invention is to provide a file system of a data processing system that decreases use of a host computer processor and memory for I/O operations.